As new technologies such as client/server architecture, object-oriented programming, multi-platform deployment, and multi-language interoperability grow, software development projects become larger and more complex. Software developers work in groups rather than individually. They share information, data and responsibilities, and various phases and levels of the software development evolve concurrently, i.e., in parallel. In such a team/parallel development process, there is a greater possibility of duplicated effort, conflict between changes made by different developers, lost changes, and the like. As a result, most software development teams use a software configuration management (or source code management) (SCM) system. An SCM system keeps track of large software development projects, and typically includes a version control system, which maintains a database or a file system for revisions of the software under development. It is able to recreate each build of the software as well as to recreate earlier environments in order to assist in the maintenance of previous versions of a software product. It may also be used to prevent unauthorized access to files or to alert the appropriate users when a file has been altered.
Some SCM systems, such as Concurrent Versions Systems (CVS) for the open source projects, Forte™ TeamWare, available from Sun Microsystems, Inc. of Palo Alto, Calif., are used for development of applications written in an object-oriented, platform-independent programming language, for example, Java™, available from Sun Microsystems, Inc. of Palo Alto, Calif. Such a versioning system may be stand alone or integrated in an Integrated Development Environment (IDE). A typical IDE has a built-in versioning system. For example, VisualAge®, available from IBM® of Armonk, N.Y., has its own repository system (not history file-based), and Forte™ For Java™, also available from Sun Microsystems, Inc., includes CVS and generic versioning system modules. However, versioning systems employed in different IDEs, or a built-in versioning system and a standalone versioning systems are typically incompatible with each other. For example, file-based versioning systems typically rely on the file system permissions for manipulating the history files and metadata, and different file systems have different metadata structures though they may use the same underlying mechanism such as Revision Control System (RCS) or Source Code Control System (SCCS). In addition, although VisualAge® can talk to TeamWare™ via a public interface using a special module, the functionality of the module is very limited.
As shown in FIG. 1, an IDE 10 complying with a component-based platform-independent specification typically runs on a software platform 12 based on object-oriented platform-independent computer language, for example, a Java based platform such as Java 2 platform Standard Edition (J2SE™) and/or Java 2 platform Enterprise Edition (J2EE™). A platform is the hardware or software environment in which a program runs. Most platforms are hardware-based and can be described as a combination of hardware and the operating system (OS), such as UNIX® (available, for example, from Tarantella Inc. (formerly Santa Cruz Operation) of Santa Cruz, Calif.), Linux® (available, for example, from Caldera Systems Inc. of Orem, Utah), Solaris® (available from Sun Microsystems, Inc. of Palo Alto, Calif.), Windows 2000 (available from Microsoft Corporation of Redmond, Wash.), Windows® NT (available from Microsoft Corporation of Redmond, Wash.), or MacOS (available from Apple Computer Corporation of Cupertino, Calif.). A software-based, platform-independent platform (such as the Java platform) differs from hardware-based platforms in that it is a software-only platform and that it runs on top of the other hardware-based platform, for example, an OS-specific platform 14 as shown in FIG. 1.
A platform-independent software platform typically includes two components: an interpreter and application programming interfaces. For example, the Java platform includes the Java Virtual Machine (Java VM) and the Java Application Programming Interface (Java API). A computer program written in Java programming language is complied into Java byte code which is a platform-independent code which is an intermediate language. The Java VM is a run-time interpreter, and it translates the Java byte code into machine language for a specific hardware-based platform. The Java API is a large collection of software components that provide many capabilities, which is typically grouped into packages of related classes and interfaces. The Java API and the Java VM insulate the program from a hardware-based platform or a specific operating system.
There are many standard API packages for the platform-independent software platform. For example, for the Java platform, there are Java™ API packages that work on input-output (java.io), collections (java.util), remote connectivity (java.rmi), Java Database Connectivity (JDBC) (java.jdbc), and the like. Such APIs provide the application (such as IDE) with various functionality via the platform-independent platform, as well as customizing the IDE. However, there is no versioning API for the platform-independent software platform. Thus, applications and IDEs that run on the software platform cannot utilize versioning functionality in a compatible, standard manner.